TSKaigi 2025
https://gyazo.com/cc5aebc58a75f3322041606279bb7cd9
そもそも高度な型を教える必要はある？
型の恩恵を得るため
誰でも読み書きできるものではない
読めないコードは負債になる
諦めるか、メンバーが読めるようになるか
課題
書き手が処理のイメージがしづらい
提案
JavaScriptで下書きでTypeScriptで翻訳する
慣れ親しんだ言語で処理を把握
型レベルプログラミングで置き換える
下書きの恩恵
処理や思考の整理ができる
デバッグが可能になる
翻訳の注意点
JSとTSは等価ではなく完全に対応するわけではない
Optional Propertyやreadonly、Unionは表現できない
ヘルパーを作ってあげる
体当たりで学 or 仕様を学ぶ必要がある
Deep Readonly
高度な型定義に慣れていない人向けに20分程度で作れるようになった
万能な手法ではない
良いところ
慣れ親しんだ言語で学べる
デバッグしやすい
修正を下書きの時点で学べる
悪いところ
ヘルパー関数つくるのが大変
AIに下準備をしてもらう
JS→TSの翻訳が自明ではない
コードネーム
Strada（既存のTypeScript実装）
Corsa（Go言語による実装）
なぜネイティブで実装するのか
パフォーマンスとスケーラビリティ
計算負荷の高い用途に最適じゃない
コンパイラの用途としては限界
なぜ移植が選ばれたのか
型チェッカーにとって後方互換性は絶対
フラグで従来のコードがコンパイルできるようにする
関数＋データ構造での手続き型の実装スタイルとの親和性
checker.tsがその状態なので…
10x Fasterの内訳
ネイティブ化
JITとdeopt
型やASTのデータ構造のインライン化、メモリの効率的な利用 オブジェクトごとにヒープに割り当てられてGCが頻発… Corsaはまとめてメモリを確保、GCコストも激減（これだけ倍速になる）
コード前提だけの用途ならほぼ半分で済む
なぜ４つなのか
型チェック結果を決定的にするために4分割で固定
将来的には
目標は99.99%の互換性
10万件のエラー差分検知テストが存在
並列化で型の結果・順番が変わるので順序を与えて決定的にする
開発スピード
自動変換→人の手を介して修正→テストで検証
AIベースの一括変換は使われていない
補助的なものは利用されている
得たパフォーマンスバジェットの使い道
型の決定的な順序付け
重い機能や改善に導入
出来た余裕を使い切らないように注意する
AIと連携するリアルタイム体験
複雑すぎる型を書いて性能の余裕を使いつぶさないようにしてほしい
フロントエンドエンジニアの強み
HTML、JS、CSS
バックエンドエンジニアの強み
インフラ
DB
サーバー構築
CI/CD
外部システム連携
BaaS, IDaaSはメリット・デメリットの検討は必須
アプリケーションによって運用体制や正解が異なる
基本的にはそう
理由
モジュールが自分の責任範囲を超えて他のモジュールの知識や制約に依存してしまっている
あとから分けるの無理
運営しながらやることは無理だと考える
ビルドプロセスの分割もできる
バージョンアップや脆弱性対応も分割できる
バックエンド言語はなんでもいい
どこでも65点とれる言語
交差型、Union型、false型
Immutable classes, properties
Attribute
パッケージマネージャ
テストランナー
PHP-CS-Fixer
開発状況
年1回のアップデート
日本人のコアメンテナも増えてきた
php.internals
PHPコミュニティ
useStateのみだと1フィールド更新するために全体再描画が起こる
本当にこれだけで大丈夫？
テストがしづらい
バリデーションも重要なロジック
バリデーションスキーマで分離する
構造と制約を宣言的に記述
フォームのモデリングを促す
フォームはプログラミングとして難しくなりやすい
入力があって、状態が構築され、同期・非同期操作があって、出力が…
表面的な難しさとプロダクトが持つ本質的な複雑さ
限界
危険なサイン
useEffectとsetStateを使いだす
Zodは制約と形状しか提供できないので合成した値の掲示とかは向いていない 自立的に修復できるようなプロンプト
コメントで自己仕様を記述させる
現状認識
結論
書きすぎない
3000行も書くと破綻する
執拗に出力を例示
ゼロショットは無理
両立条件の矛盾を避ける
矛盾すると性能が下がる
段階的に厳して行く